As the Internet continues to serve increasingly sophisticated purposes necessarily changing the way information is communicated, shared, and used, companies having a presence on the Internet have experienced challenges relating to the warehousing of their information. For instance, the introduction of transactional and user-driven features to the Internet paradigm have required a shift from static information models to those more readily promoting greater accessibility to and manipulation of information. One approach in meeting these new demands and better expediting the exchange and use of information, is the Representational State Transfer (REST) model of software architecture.
Under REST, a website can expose information for consumption by others through a web service. A particularly sophisticated website may have a number of associated web services, each addressing a distinct function relating to the storage, retrieval, and manipulation of information. For these RESTful web services, the concept of a resource—a specific source of information referenced using a global identifier—is a central principle. By specifying the appropriate global identifier, a resource can be subject to a set of CRUD-like operations (Create Read Update Delete) collectively known as resource methods; accordingly, invoking resource methods for a particular resource, allows the information associated with the web service through that particular resource to be stored, retrieved, or manipulated.
In making its information easily consumable by third parties, an Internet company provides an application programming interface (API) to facilitate interactions with its web services. By virtue of the API, a developer can create a client application that uses the information associated with the website beneficially for both the website and some ultimate end-user; however, to properly safeguard the information, a need arises for the website to authenticate the client application whenever such access is sought. In addressing that, an authentication mechanism is in place for whenever the client application using the API effectively invokes a web service resource method associated with the website.
One of the challenges facing client application developers is addressing the variety of possible authentication mechanisms that may be required from one web service to the next. Adding to the complexity of the challenge is the scenario where a web service requires a customized authentication mechanism that is not widely known or widely used. For these reasons, complying with a required authentication mechanism for a particular web service can be a burden inflicting some cost with regards to time and effort upon the application developer. This burden is even greater for an application developer tailoring their a client application for consumption of a variety of web services.